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Proposal  for  a  New  "Rights  In  Software”  Clause  for 
Software  Acquisitions  by  the  Department  of  Defense 

Pamela  Samuelson,  Kevin  Deasy,  Anne  C.  Martin 


ABSTRACT.  t.  report  recommends  three  distinct  regulatory  strategies  tor  addressing  dH- 
ficuMae  the  Department  of  Defense  (DoD)  has  been  experiencing  with  respect  to  legal  issues 
refated  to  softwiue  acquisitions.  First,  the  report  reiterates  the  Software  Licensing  Project’s  earlier 
recommendation  that  the  DoD  adopt  the  proposed  Federal  Acquisition  Regulation  (FAR)  data 
rights  provisions  instead  of  the  proposed  revisions  to  the  DoD  supplement  to  the  FAR  (DoD  FAR 
SUPP). 

Seconder,  in  the  event  diet  the  Defense  Department  chooses  to  adopt  a  data  rights  procurement 
polcy  ddferent  from  that  found  in  the  data  rights  provisions  of  the  proposed  FAR,  this  report 
recommends  that  the  DoD  adopt  a  separata'  TUghts  in  Software”  clause  tor  software  acquisitions, 
rather  than  continuing  the  present  practice  of  handling  software  procurements  under  the^Rights  in 
Technical  Data*  effuse.  Reasons  in  support  of  a  separate  software  acquisition  policy,  as  well  as  a 
beginning  model  Tights  in  Software”  clause  are  offered. 

Finally,  in  the  event  that  the  DoD  elects  to  retain  the  procurement  format  presently  found  in  the 
DoD  FAR  SUPP  provisions  governing  software  and  technical  data  acquisitions,  this  report  offers 
several  concrete  recommendations  for  changes  to  those  regulations  which  should  result  in  a 
procurement  policy  which  more  effectively  meets  the  mission  needs  of  the  Defense  Department. 


1.  Background 

The  Software  Licensing  Project  (SLP)  of  the  Software  Engineering  institute  (SEI)  has  written  two 
previous  reports  on  the  Department  of  Defense's  (DoD)  software  acquisition  policy.  The  first  of 
these  reports  was  Toward  a  Reform  of  the  Defense  Department  Software  Acquisition  Policy,” 
CMU/SE1-86-TR1  [Reform  86]  (hereinafter  referred  to  the  "First  Report”).  It  surveyed  a  range  of 
problems  that  DoD  personnel  had  identified  as  software  licensing  problems  currently  being  ex¬ 
perienced  by  DoD.  One  chapter  of  the  First  Report  was  devoted  to  an  analysis  of  the  data  rights 
regulations  that  govern  acquisitions  of  software  by  DoD.  The  First  Report  concluded  that  a 
substantial  revision  of  DoD's  standard  data  rights  clause  would  be  desirable. 

The  second  SLP  report  was  "Comments  on  the  Proposed  Federal  and  Defense  Acquisition 
Regutsfiona,”  SEI-86-TM2  [Comments  86]  (hereinafter  referred  to  as  the  "Second  Report”).  It 
recommended  that  the  Department  of  Defense  adopt  the  proposed  Federal  Acquisition  Regula¬ 
tion  (FAR)  data  rights  provisions  instead  of  Its  proposed  revisions  to  its  supplement  to  the  FAR 
data  rights  regulations.  The  Second  Report  made  this  recommendation  for  four  reasons: 
(1)  The  proposed  FAR  data  rights  regulations  present  a  more  concise  and  comprehensible 
regulatory  scheme  than  either  the  current  or  proposed  DoD  regulations.  (2)  The  proposed  FAR 
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data  rights  policy  is  also  more  compatble  with  standard  software  commercial  practices  and 
provides  more  incentives  for  industry  to  make  its  best  technology  available  to  the  government 
than  does  the  DoD  policy.  (3)  At  the  same  time,  the  proposed  FAR  data  rights  policy  would  give 
to  the  government  a  number  of  rights  that  DoD  would  seem  to  need  to  fulfill  its  mission  (including 
rights  which  the  current  and  proposed  DoD  regulations  fail  to  claim  for  DoD).  (4)  Both  statutory 
and  polcy  reasons  support  having  a  uniform  set  of  federal  data  rights  regulations  rather  than 
having  two  poides,  one  for  DoD  and  one  for  all  other  federal  agencies. 

This  report  is  die  third  SLP  Report  to  concern  itself  with  the  DoD  procurement  regulations  affect¬ 
ing  software.  While  we  continue  to  stand  on  our  recommendation  that  DoD  adopt  the  FAR  data 
rights  provisions,  we  understand  that  for  various  reasons,  the  Department  of  Defense  may  find  it 
undesirable  to  adopt  the  proposed  FAR  data  rights  policy  and  may  decide  to  continue  with  its 
separate  data  rights  policy. 

In  the  event  that  DoD  chooses  to  continue  its  separate  approach  to  software  acquisitions,  we 
would  have  the  Department  of  Defense  consider  three  further  recommendations  which  are  set 
forth  in  this  report.  First,  we  recommend  that  the  DoD  create  a  separate  "standard  rights  in 
software  clause",  that  is,  to  break  software  out  of  the  standard  technical  data  rights  clause.  Some 
part  of  the  reason  why  DoD  has  experienced  so  much  difficulty  in  its  software  acquisition  policy 
is,  we  believe,  due  to  the  quasMechnical-data-rights  orientation  of  its  present  policy,  an  orien¬ 
tation  which  is  inappropriate  for  software  acquisitions. 

Second,  we  offer  a  draft  standard  "rights  in  software"  clause  for  DoD's  consideration.  This  clause 
provides  for  separate  treatment  of  software  acquisitions,  distinct  from  that  accorded  technical 
data  under  the  standard  data  rights  clause.  This  "rights  in  software”  clause  presents  several 
unique  features  which  distinguish  it  from  the  standard  data  rights  clause.  These  include:  the 
inclusion  of  software  documentation  within  the  definition  of  the  term  "software,"  the  establishment 
of  government  purpose  rights  as  the  standard  "ceiling"  of  rights  that  the  government  obtains  in 
publicly  funded  software,  and  the  provision  that  software  will  retain  its  restricted  rights  status  even 
when  slight  modifications  are  made  at  the  request  of  the  government. 

Third,  in  the  event  that  DoD  chooses  not  to  adopt  our  first  two  recommendations,  and  decides  to 
retain  the  basic  structure  and  content  of  the  existing  standard  data  rights  clause,  there  are  still  a 
number  of  specific  changes  to  that  clause,  as  It  affects  software,  that  we  believe  would  be  in  the 
government's  best  interest  to  adopt.  There  are  22  specific  recommendations  for  changes  to  the 
text  of  the  DoD  standard  data  rights  clause  discussed  within,  all  of  which  would,  in  our  view, 
improve  DoD's  software  acquisition  process. 
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2.  Issues 

2.1  Should  DoD  Adopt  a  "Standard  Rights  In  Software  Clause"  and  Take 
Software  Out  of  die  Technical  Data  Rights  Clause? 

For  well  over  a  decade,  DoD  has  acquired  rights  in  software  by  means  of  the  same  standard 
clause  as  that  used  to  acquire  rights  in  technical  data  (DoD  FAR  SUPP  sec.  52.227-7013,  also 
known  as  the  standard  data  rights  clause,  referred  to  hereinafter  as  "SDRC").  We  understand 
that  the  Department  is  currently  considering  adopting  a  separate  clause  for  its  acquisitions  of 
rights  in  software,  that  is,  breaking  software  out  of  the  technical  data  rights  provisions  of  the 
SDRC.  Although  we  believe  that  the  Department  can  have  a  substantially  improved  software 
acquisition  policy  without  such  radical  surgery  to  the  SDRC  (after  all,  we  have  recommended 
adoption  of  the  FAR  data  rights  policy  which  retains  a  unified  technical  data  and  software  policy), 
we  believe  that,  on  the  whole,  the  Department  would  be  well  served  by  making  the  change  to  a 
separate  rights  in  software  policy  for  the  reasons  discussed  below. 

2.1.1  Reasons  that  Support  a  Separate  "Rights  In  Software"  Policy 

2.1 .1.1  The  current  DoD  policy  already  partially  differentiates  software  from  technical 
data. 


Although  DoD  has  long  had  a  policy  of  acquiring  rights  in  software  under  the  same  SDRC  that  is 
used  in  acquisitions  of  rights  in  technical  data,  software  has  for  some  time  been  partially  differen¬ 
tiated  from  technical  data  within  the  body  of  the  SDRC.  The  most  obvious  difference  is  in  the 
rights  the  government  takes  as  a  matter  of  course  in  privately  developed  software,  as  compared 
with  privately  developed  technical  data.  Software’s  "restricted  rights"  are  very  restrictive  (e  g.,  to 
particular  computers)  as  compared  with  technical  data’s  "limited  rights’  which  permits  use  or 
copying  throughout  the  government.  This  reflects  that  the  Department  has  already  recognized 
that  software  and  technical  data  flrg  different.  The  SDRC  also  recognizes  that  the  rights  that  the 
government  needs  in  software,  and  the  limitations  that  are  reasonable  for  industry  to  impose  on 
the  government's  rights  in  software  flrg  different  from  those  that  pertain  to  technical  data. 

The  question  we  have  been  raising  is  whether  software  is  differentiated  enough  in  the  SDRC  and 
differentiated  in  the  right  ways.  For  various  reasons  discussed  in  our  First  Report,  we  believe  that 
DoD  has  not  yet  adequately  differentiated  between  technical  data  and  software.  This  is  why,  we 
believe,  derivative  works  rights  which  are  critically  important  as  to  software,  have  been  omitted 
from  the  technical  data  oriented  SDRC,  which  defines  unlimited  rights  without  reference  to  a  right 
to  make  derivative  works.  A  separate  software  clause  would  facilitate  appropriate  differentiation 
between  software  and  technical  data. 

2.1.1 .2  Economic  reaeons  why  software  documentation  should  be  treated  differently  from 
technical  data. 

The  function  and  purpose  of  software  is  different  from  that  of  technical  data.  Software  performs 
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tasks;  technical  data  merely  conveys  information.  Because  of  this,  the  economics  underlying  the 
development  and  marketing  of  software  and  technical  data  are  significantly  different.  Software 
generally  involves  significant  research  and  development  costs  which  can  only  be  recouped 
through  the  marketing  of  the  product,  software  itself,  whereas  technical  data  is  generally 
produced  as  an  ancfllary  step  in  the  process  leading  to  production  of  the  actual  Hem  to  be 
marketed. 

The  critical  point  here  is  that  the  capital  cost  of  design  and  development  (including  the  cost  of 
software  tools  and/or  CAD/CAM  programs  which  aided  in  the  development  effort)  are  recouped 
as  part  of  the  sale  of  the  system,  not  through  sales  of  technical  data  that  might  have  been 
generated  in  developing  the  system.  DoD's  policy  with  respect  to  hardware  systems  takes  this 
into  account  by  treating  hardware  systems  in  a  manner  different  than  it  treats  technical  documen¬ 
tation.  DoD's  present  policy  with  respect  to  software,  however,  is  heavily  technical  data  oriented, 
and  does  not  allow  software  design  costs  to  be  recovered  in  the  same  manner. 

Thus,  the  economics  of  software  development  indicate  a  need  for  breaking  software  (and  the 
documentation  which  is  an  integral  part  of  its  development  and  evolution)  out  from  the  quasi- 
technical  data  treatment  it  has  thus  far  received.  With  regard  to  development  costs  and 
capitalization,  software  is  in  many  ways  more  Ike  a  hardware  component  than  it  is  like  the  tech¬ 
nical  documentation  which  supports  the  hardware.  The  DoD  procurement  policy  needs  to  be 
structured  so  as  to  take  account  of  these  technical  and  economic  similarities  between  software 
and  hardware,  as  wel  as  the  dissimilarities  between  software  and  technical  data. 

This  policy  should  also  recognize  that  unlike  hardware,  software  is  an  evolutionary  product  -  that 
is,  it  is  in  a  state  of  constant  development  as  maintenance  and  enhancement  work  is  continually 
done  to  improve  upon  and/or  alter  the  functioning  of  the  software.  As  an  evolutionary  product, 
the  documentation  supporting  the  software  is  in  fact  a  critical  part  of  the  software  product  itself. 
For  this  reason,  the  software  documentation  should  be  treated  in  the  same  manner  as  the  ex¬ 
ecutable  version  of  the  program.  A  properly  structured  software  acquisition  clause  can  ac¬ 
complish  this. 

2.1 .1.3  Outside  of  the  DoD  regulations,  different  Intellectual  property  rights  may  attach  to 
software  than  to  technical  data. 

Software  is  a  unique  intellectual  property  in  that  it  can  be  protected  under  the  copyright  law,  trade 
secret  law,  and  patent  law.  The  unique  nature  of  software  allows  it  to  be  copyrighted  without 
revealing  all  of  its  "secrets"  which  means  that  trade  secret  and  copyright  protection  can  coexist  in 
the  same  subject  matter.  It  is  rare  for  a  firm  to  copyright  technical  data  that  the  firm  wanted  to 
claim  as  a  trade  secret,  because  the  Copyright  Office  generally  makes  any  deposited  work  avail¬ 
able  for  public  inspection  and  copyright  law  treats  such  things  as  manufacturing  instructions  or 
engineering  designs  as  "ideas"  which  are  in  the  public  domain.  Firms  tend  to  keep  manufacturing 
instructions  and  other  technical  data  solely  as  trade  secrets.  A  separate  clause  to  govern 
software  acquisitions  could  take  into  account  differences  in  intellectual  property  protection  affect¬ 
ing  software  and  technical  data. 
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2.1 .1.4  The  educational  value  of  a  separate  eoftware  clauM. 

A  new  clause  to  govern  software  acquisitions  could  accomplish  a  break  with  the  past,  and  en¬ 
gender  a  move  away  from  the  quasi-data  rights  orientation  which  has  pervaded  software  acquisi¬ 
tions.  A  new  clause  could  pave  the  way  to  a  new  "mind  set"  for  these  who  work  in  the  area  of 
software  and  data  rights  acquisitions.  Such  a  clause  would  provide  a  point  of  departure  for 
re-educating  procurement  personnel  regarding  the  nature  of  software,  in  this  way,  it  could  create 
a  fresh  way  of  viewing  software  acquisitions,  one  more  in  line  with  the  economic  and  technologi¬ 
cal  realities  of  the  software  industry. 

2.1 .1.5  Improving  relations  with  Industry. 

It  is  unfortunate  Burt  relations  between  the  software  industry  and  the  Department  of  Defense  are 
at  present  somewhat  strained  over  software  data  rights  issues.  Many  industry  representatives 
seem  to  feel  that  DoD  software  procurement  policy  is  confiscatory.  The  adoption  of  a  separate 
clause  to  govern  software  acquisitions,  which  would  break  such  acquisitions  out  from  the  policies 
with  which  industry  has  been  unhappy,  could  go  far  to  improve  government-industry  relations.  At 
the  very  least,  the  perception  that  DoD  is  making  some  effort  to  alleviate  the  areas  of  conflict  with 
industry  could  be  valuable  in  this  regard. 

2.1.2  Reasons  not  to  Adopt  a  Separate  Software  Acquisition  Clause 

2.1 .2.1  The  overtap  between  software  and  technical  data. 

A  separate  software  clause  is  not  necessary  to  significantly  improve  the  DoD’s  software  acquisi¬ 
tion  policy.  Even  we  conclude  that  the  FAR  data  rights  policy,  which  retains  a  unified  approach, 
would  be  an  excellent  policy  for  DoD.  This  is  one  reason  not  to  break  software  out  of  the 
technical  data  clause.  There  are  others  as  welt. 

There  is,  for  instance,  some  artifice  in  the  distinction  between  software  and  technical  data.  Tech¬ 
nical  data  can  be  incorporated  into  a  computer  data  base,  for  example,  which  would  seem  to 
transform  it  into  software.  In  fact,  virtually  anything  that  can  be  written  on  paper  can  be  trans¬ 
formed  into  a  machine  readable  form.  The  DoD  would  need  to  sort  out  the  computerized  tech¬ 
nical  data  problem  which  its  present  regulations  also  fail  to  do  but  apart  from  this,  software  and 
technical  data  are  sufficiently  distinct  that  a  separate  policy  is  appropriate,  as  DoD’s  present 
SDRC  already  demonstrates. 

2.1 .2.2  Would  DoD  seem  to  be  "caving  In"  to  Industry  If  it  adopted  a  separate  software 
clausa? 

Since  software  resembles  technical  data  and  has  long  been  treated  within  the  technical  data 
policy,  and  since  the  software  industry  has  been  lobbying  for  a  special  software  policy,  one 
problem  that  DoD  may  see  with  a  separate  software  clause  is  that  it  may  appear  to  some  that  the 
DoD  would  be  too  generous  to  industry,  especially  if  the  Department  allows  industry  to  retain 
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greater  rights  in  software  than  in  technical  data.  DoO's  response  to  such  charges  should, 
however,  be  that  the  differential  treatment  of  software  would  actually  save  the  government  money 
in  that  the  government  would  not  be  forced  by  the  regulations  into  purchasing  the  more  expensive 
"government-wide  rights"  to  software  documentation  in  those  instances  where  a  site  license  is 
adequate  to  the  needs  of  the  government  and  that  better  software  at  lower  development  costs  will 
be  made  available  to  the  government  if  it  provides  better  incentives  to  the  software  industry. 
Such  responses  should  serve  to  silence  the  critics. 

2.1 .2.3  The  need  to  retrain  DoO’a  contracting  personnel  as  to  any  new  software  clause. 

A  separate  rights  clause  to  govern  software  acquisitions  has  the  potential  to  further  complicate 
the  DoD  acquisition  process.  Those  who  have  long  experience  with  the  SDRC  have  become 
used  to  muddling  through  the  present  system.  They  would  have  to  be  retrained  about  rights  in 
software,  and  this  is  no  smalt  job. 

The  DoD  needs,  Kke  private  industry,  to  be  involved  in  the  evolution  of  a  conceptualization  of 
software  and  software  acquisition  which  is  consistent  with  the  technological,  economic  and  legal 
realities  of  software  development.  A  separate  treatment  for  software,  along  with  the  retraining 
which  would  need  to  be  undertaken  in  conjunction  with  such  a  change,  could  go  a  long  way 
toward  developing  a  new  and  more  dynamic  conceptual  framework  for  dealing  with  software. 

2.1 .2.4  The  desirability  of  an  overhaul  of  the  DoD  procurement  policy  as  to  intellectual 
property. 

The  DoD  would  benefit  greatly  from  a  more  substantial  overhaul  of  the  procurement  regulations 
to  make  them  more  compatible  with  traditional  and  newly  developing  intellectual  property  law.  A 
more  integrated,  more  unified  intellectual  property  policy  could  bring  together  DoD's  policies  as  to 
copyright,  patent,  semi-conductor  chip  design,  trade  secret  and  trademark  law.  Advances  in  new 
technologies  are  bringing  together  and  blurring  the  the  lines  between  these  traditional  forms  of 
InteHectual  properly  protection.  As  the  new  technologies  continue  to  advance,  the  need  to  in- 
’ograte  policies  in  these  areas  will  become  more  acute.  Additionally,  government  attorneys  work¬ 
ing  in  the  software/data  rights  area  must  of  necessity  have  some  grounding  in  the  traditional 
forms  of  intellectual  property  law.  Given  this,  it  seems  wise  for  DoD  to  draw  upon  the  knowledge 
and  expertise  already  possessed  by  its  lawyers  involved  in  this  area  by  making  its  policies  consis¬ 
tent  with  the  already  existing  body  of  intellectual  property  law. 

A  separate  clause  for  software  acquisitions  will  contribute  to  a  fractionated  rather  than  a  unified 
system  of  intellectual  property  regulations.  The  time  and  energy  expended  in  adopting  a 
separate  software  acquisition  clause  would  probably  be  at  the  expense  of  efforts  which  might 
otherwise  have  been  invested  in  developing  a  broader,  more  integrated  intellectual  property 
policy  for  the  department,  a  policy  which  needs  generally  to  be  more  integrated  with  copyright 
and  trade  secret  law. 
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2.1  J3  Conclusion 

On  the  balance,  we  believe  that  the  advantages  presented  by  a  separate  software  acquisition 
clause  outweigh  the  potential  disadvantages.  We  would  recommend,  therefore,  that  the  DoD 
adopt  a  software  acquisition  clause  as  part  of  its  procurement  regulations.  A  suggested  model 
clause  is  included  in  this  report.  It  should  be  noted  that  the  clause,  while  offering  a  fresh  ap¬ 
proach  to  software  acquisition,  only  touches  briefly  on  software  maintenance  and  enhancement. 
In  recognition  of  the  critical  importance  of  these  issues,  the  next  phase  of  this  project’s  research 
will  focus  specifically  on  these  issues.  A  more  in-depth  treatment  of  maintenance  and  enhance¬ 
ment  will  be  forthcoming  with  the  project  s  next  report. 

2.2  What  Might  a  Standard  Rights  in  Software  Clause  Look  Like? 


2.2.1  The  Model  Standard  Rights  In  Software  Clause 
(a)  Definitions 

As  used  in  this  clause,  the  following  terms  have  the  following  meanings: 


government  purpose 

the  fulfillment  of  a  legitimate  federal  government  function,  including  uses  or 
disclosures  for  competitive  reprocurements  and  maintenance  and  enhance¬ 
ment  purposes;  the  term  includes  disclosure  to  and  use  by  other  contractors 
and  any  state,  local  or  foreign  government  where  such  disclosure  or  use  will 
fulfill  a  legitimate  federal  government  purpose;  the  term  does  not  include  a 
general  distribution  of  the  software  to  defense  contractors  or  other  more 
limited  distributions  of  the  software  that  may  have  a  significant  negative  effect 
on  the  commercial  market  for  such  software.  Nor  does  it  include  a  disclosure 
that  permits  the  recipient  to  disseminate  the  software  without  restriction  or  to 
develop  software  for  non-governmental  sales  in  competition  with  the  owner  of 
intellectual  property  rights  in  it. 

government  purpose  license 

a  license  to  the  federal  government  that  grants  the  government  rights  to  use, 
duplicate,  disclose,  distribute,  prepare  derivative  works,  and  publicly  display 
software  for  government  purposes,  and  to  authorize  others  to  exercise  such 
rights  when  doing  so  will  fulfill  a  legitimate  federal  governmental  function. 
When  software  provided  to  the  government  by  one  contractor  is  distributed  or 
dteclosed  by  the  government  to  a  subsequent  contractor  for  a  government 
purpose,  the  subsequent  contractor  shall  be  bound  by  the  terms  of  the 
government  purpose  license. 

restricted  rights  license 

a  license  to  the  federal  government  that  at  a  minimum  grants  the  government 
rights 

(1 )  to  use  software  in  the  computer  for  which  the  software  was  ac¬ 
quired; 

(2)  to  use  software  in  a  backup  computer  if  the  computer  for  which  it 
was  acquired  becomes  inoperable; 
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(3)  to  make  copies  of  the  software  necessary  for  backup  and  reverse 
engineering  purposes;  (4)  to  adapt  and  modify  the  software;  and 

(5)  to  authorize  support  contractors  to  exercise  the  rights  described 
in  (1)  through  (4),  subject  to  the  same  restrictions  as  bind  the  government. 

restricted  rights  software 

software  that  has  been  developed  at  private  expense,  including  software  as 
to  which  only  slight  modifications  are  made  to  adapt  it  for  the  government 
needs  with  public  funds.  The  term  "developed”  means  fixed  in  a  tangible 
medium  of  expression.  The  term  "at  private  expense”  means  entirely  funded 
by  the  contractor  and  without  any  government  reimbursement,  direct  or  un¬ 
direct  other  than  through  IR&D  cost  allocations. 

software  computer  programs,  computer  data  bases,  and  documentation  pertaining 

thereto  including  but  not  limited  to  such  programs  in  any  machine  readable 
printed  or  interpreted  form,  system  reference  manuals  and  user  manuals. 

(b)  Rights  of  the  Government  (1)  Public  Domain  Software:  There  shall  be  no  restric¬ 

tions  on  the  government's  right  to  use,  duplicate,  disclose,  distribute,  display  or  make  derivatives 
of  software  that  is  in  the  public  domain. 

(2)  Government  Purpose  Licenses:  The  government  shall  have  a  government  purpose 
license  in  all  software  deliverable  under  this  contract  that  was  developed  at  public  expense.  The 
government  may  also  negotiate  to  obtain  a  government  purpose  license  in  software  that  was 
developed  at  private  expense. 

(3)  Restricted  Rights  License:  The  government  shall  have  a  restricted  rights  license  in 
all  restricted  rights  software  deliverable  under  this  contract.  Written  permission  of  the  owner  of 
such  software  will  be  required  before  the  government  may  make  or  authorize  other  uses  or  dis¬ 
closures  of  this  software. 

(4)  Negotiating  for  Additional  Rights:  The  government  may  negotiate  to  obtain  more 
rights  in  restricted  rights  software  than  the  five  standard  rights  that  are  named  in  the  definition  of 
the  restricted  rights  license.  Additionally,  the  government  and  contractor  may  negotiate  to  define 
the  uses  the  government  may  make  of  software  within  the  scope  of  the  government  purpose 
license. 

(5)  Incorporation  of  Other  Software:  When  a  contractor  incorporates  into  software  to  be 
delivered  to  the  government  modules  or  subroutines  in  which  the  contractor  does  not  own  all 
intellectual  property  rights,  the  contractor  shall  obtain  tor  the  government  at  least  a  restricted 
rights  license  in  such  incorporated  modules  or  subroutines. 

(6)  Rights  from  Subcontractors-.  The  government  shall  have  the  same  minimum  rights  in 
software  developed  by  subcontractors  as  in  software  developed  by  prime  contractors. 

(7)  Challenging  Restrictive  Legends:  The  government  may  challenge  inappropriate 
restrictive  legends. 
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(c)  Right*  of  Contractors  and  Subcontractors 

(1)  Ownership:  Unless  the  special  works  clause  has  been  invoked,  whoever  develops 
software  deliverable  under  this  contract  shall  be  considered  the  owner  of  all  intellectual  property 
rights  in  X,  subject  to  a  restricted  rights  or  government  purpose  license  to  the  government  as 
provided  in  Section  (b). 

(2)  Restrictive  Markings:  The  contractor  or  subcontractor  who  owns  intellectual  property 
rights  in  software  may  attach  appropriate  restrictive  markings  to  the  software  in  accordance  with 
this  clause. 

(3)  Direct  Delivery  to  the  Government:  Subcontractors  under  this  contract  may  deliver 
restricted  rights  software  directly  to  the  government  rather  than  to  the  prime  contractor  unless  the 
software  is  needed  by  the  prime  contractor  for  installation  in  the  system  that  the  contractor  is 
required  to  deliver  to  the  government. 

(4)  No  Leverage:  Neither  the  prime  contractor  nor  any  intermediate  subcontractor  shall 
use  its  power  to  award  subcontracts  as  a  means  of  acquiring  greater  rights  in  software  from  its 
subcontractors  than  is  needed  to  perform  the  government  contract. 

(5)  Fiowdown  to  Subcontractor  Whenever  any  software  is  to  be  obtained  from  a  sub¬ 
contractor  under  this  contract,  the  contractor  shall  use  this  same  clause  in  the  subcontract,  with¬ 
out  alteration.  No  other  clause  shall  be  used  that  will  enlarge  or  diminish  either  the  government’s 
or  the  contractor's  rights  in  the  subcontractor’s  software  which  is  to  be  delivered  to  the  govern¬ 
ment. 


(d)  Restrictive  Legends 

(1)  No  Marking  If  In  Public  Domain:  Software  that  is  in  the  public  domain  shall  be 
delivered  with  no  restrictive  markings. 

(2)  Government  Purpose  Rights  Leoend:  Software  in  which  the  government  has 
government  purpose  rights  is  to  be  delivered  to  the  government  with  the  following  restrictive 
legend: 

Government  Purpose  Rights 
Property  of:  (contractor  or  subcontractor’s  name) 

Standard  Restricted  Riohts  Leoend:  Restricted  rights  software  in  which  the  government  has  only 
the  standard  five  minimum  rights  are  to  be  delivered  to  the  government  with  the  following  restric¬ 
tive  legend: 

Restricted  Rights 

Property  of:  (contractor  or  subcontractor’s  name) 
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(4)  Other  Restricted  Rights  Leoend:  When  the  government  and  the  contractor  (or 
subcontractor)  have  negotiated  an  arrangement  whereby  the  government  wW  get  more  than  the 
standard  five  minimum  rights  in  restricted  rights  software,  the  software  shaft  be  delivered  with  the 
folowing  restrictive  legend: 


Expanded  Restricted  Rights 
Property  of:  (contractor  or  subcontractor's  Name) 

Contract  No: _ 

(5)  Copyright  Notices:  Unless  the  special  works  clause  has  been  invoked,  the  owner  of 
inteSectual  property  rights  in  software  may  attach  appropriate  copyright  notices  to  software 
delivered  under  this  contract. 


23.2.  Commentary  to  the  Model  Standard  Rights  in  Software  Clause 

There  are  a  number  of  respects  in  which  this  standard  rights  in  software  clause  differs  from  the 
SDRC,  among  them: 

•  that  software  is  defined  to  include  documentation; 

•  that  governmental  purpose  rights  are  the  standard  ■ceiling'  of  rights  that  the  govern¬ 
ment  has  in  publicly  funded  software; 

•  that  there  is  no  differentiation  in  the  level  the  government’s  rights  dependent  on 
whether  or  not  the  contractor  copyrights  the  software; 

•  that  the  government  wfll  have  a  right  to  prepare,  or  authorize  preparation  of,  deriva¬ 
tive  software  from  software  developed  at  public  expense; 

•  that  software  will  not  lose  Is  restricted  rights  status  if  only  slight  modifications  are 
made  to  I  at  the  request  of  the  government; 

•  that  use  by  support  contractors  (subject  to  restrictions  binding  the  government)  is 
included  in  the  set  of  restricted  rights; 

•  that  "developed"  is  defined  in  a  manner  more  consistent  with  copyright  than  patent 
standards; 

•  that  no  explicit  reference  is  made  as  to  the  contractor's  right  to  claim  a  copyright 
because  we  regard  this  as  implicit  in  the  clause’s  recognition  of  the  developer's  right 
to  intellectual  property  rights  in  the  software. 

Before  discussing  some  of  these  features,  it  may  be  helpful  to  descrfoe  the  circumstances  in 
which  we  would  envision  this  clause  being  used. 

2.22.1  The  qussHnandatory  nature  of  the  standard  clause. 

The  SDRC  is  required  to  be  inserted  in  all  Defense  Department  software  acquisition  contracts. 
The  present  SDRC  contemplates  two  situations  in  which  the  government’s  rights  in  the  software 
may  be  different  than  those  that  the  SDRC  Itself  prescribes: 

1.  When  the  government  uses  the  special  works  clause  in  a  software  development 
contract,  and 

2.  When  the  contractor  and  the  government  negotiate  an  agreement  giving  the 
government  more  than  the  four  standard  minimum  rights  in  privately  developed 
software. 
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The  SDRC  w«  govern  al  rights  in  software  matters  unless  one  of  these  circumstances  is  present. 
Our  proposed  standard  software  clause  would  operate  in  much  the  same  fashion.  That  is,  it 
would  be  a  mandatory  clause  for  insertion  into  ail  DoD  software  acquisition  contracts  unless  one 
of  a  set  of  authorized  alternate  rights  acquisition  clauses  was  used  in  the  contract.  We  would 
recommend  retention  of  the  two  already  authorized  alternatives,  and  would  recommend  serious 
consideration  of  two  other  authorized  alternatives,  one  permitting  the  government  to  negotiate  for 
less  than  government  purpose  rights  when  there  is  substantial  private  funding  of  the  software's 
development  in  addition  to  some  public  funding,  and  another  for  acquiring  less  than  the  standard 
set  of  minimum  rights  in  software  tools  and  CAD/CAM  programs. 

2.2J2J2  A  "mixed  binding"  alternative  to  equitably  distribute  rights  based  on  public  and 
private  funding. 

As  one  alternative  to  the  standards  “rights  in  software”  clause,  the  DoD  should  consider  adopting 
a  clause  which  would  equitably  allocate  rights  in  software  in  mixed  funding  situations.  The  DoD 
Authorization  Act  of  1985  seems  to  contemplate  adoption  of  a  data  rights  policy  that  differentiates 
between  whotty  government  funded  and  partly  government  funded  projects.  DoD's  present 
regulations  have  not  responded  to  this  Congressional  directive.  The  DoD  would,  of  course,  need 
to  address  issues  regarding  what  forms  of  contribution  to  a  project  constitute  private  funding 
(resources  or  cash),  what  degree  of  private  funding  would  be  necessary  to  trigger  the  mixed 
funding  alternative,  how  much  flexbility  to  allow  contracting  personnel  in  structuring  mixed  fund¬ 
ing  arrangements,  and  the  Hke. 

2.2.2 .3  An  alternative  clause  to  obtain  less  than  the  standard  minimum  rights  In  software 
tools  and  CAD/CAM  programs. 

AddMonaly.  the  DoD  might  consider  adopting  another  alternative  allocation  of  rights  clause,  one 
which  would  allow  toe  DoD  to  obtain  less  than  minimum  rights  in  certain  items  such  as  software 
tools  and  computer  aided  design/computer  aided  manufacturing  (CAD/CAM  programs).  Since 
software  tools  and  CAD/CAM  programs  are  such  valuable  resources  of  private  firms,  contractors 
are  loath  to  provide  these  tools  to  the  government  under  the  standard  rights  arrangements.  It 
would  seem  that  DoD  would  be  wise  to  provide  in  its  regulations  the  flexibility  to  negotiate  for 
some  access  to  these  items,  on  the  theory  that  partial  access  will  in  some  instances  be  better 
than  none  at  all.  M  is  in  DoD's  interest  to  assure  contractors  that  they  can  provide  their  best 
technology  to  the  DoD  without  fear  of  loss  of  these  rights  in  their  software. 

2.2J2A  Why  government  purpose  rights  Is  the  standard  celling  of  rights  under  the  clause 
Instead  of  unlimited  rights. 

As  our  First  Report  has  indicated,  it  seems  that  under  the  standard  data  rights  clause  the  govern¬ 
ment  now  obtains  government  purpose  rights  rather  than  unlimited  rights  in  publicly  funded 
software  in  which  the  contractor  claims  a  copyright.  It  is  not  clear  why  the  government  has 
chosen  to  provide  this  incentive  to  contractors  to  copyright  software.  After  studying  this  matter, 
we  have  concluded  that  there  should  not  be  a  difference  in  the  extent  of  the  government’s  rights 
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depending  on  whether  the  software  is  copyrighted  by  the  contractor.  Because  it  appears  that  the 
government  is  already  willing  to  accept  government  purpose  rights  for  copyrighted  software 
developed  at  public  expense,  we  believe  it  is  reasonable  for  the  government  to  use  the  same 
policy  as  to  afl  publicly  funded  software.  Indeed,  we  fail  to  see  why  the  government  would  ever 
need  more  than  government  purpose  rights  in  publicly  funded  software. 

2.2J2JS  The  definition  of  the  term  "developed"  should  be  grounded  in  principles  of 
copyright  law. 

The  approach  DoD  has  taken  toward  defining  "developed"  within  the  meaning  of  "developed  at 
private  expense"  has  been  a  patent-oriented  definition  of  the  term.  Indeed,  the  government's 
patent  lawyers  seem  to  have  diligently  and  aggressively  attempted  to  use  a  patent  standard 
toward  software  development  so  as  to  establish  for  the  government  as  broad  a  set  of  rights  as 
possble  in  software.  As  discussed  in  the  First  Report,  one  result  of  claiming  this  broad  set  of 
rights  for  the  government  has  been  to  create  significant  disincentives  for  contractors  to  deliver 
their  best  technology  to  the  government. 

The  model  clause  takes  a  more  copyright-lfce  approach  to  defining  "developed."  Because 
software  is  copyrightable,  and  copyright  law  allows  intellectual  property  rights  to  attach  whenever 
a  work  is  fixed  in  a  tangible  medium  of  expression,  it  seems  appropriate  for  the  government 
regulations  applicable  to  software  to  be  more  consistent  with  this  body  of  intellectual  property  law 
(which  is,  alter  all,  the  most  important  body  of  federal  intellectual  law  affecting  software). 
(Although  software  may  sometimes  be  patentable,  software  patents  are  much  rarer  than  software 
copyrights.)  A  copyright  approach  to  a  definition  of  "developed"  would  also  be  more  consistent 
with  the  nature  of  the  software  development  process.  Unlike  hardware,  software  is  almost  con¬ 
tinually  in  the  process  of  development.  Copyright  law  which  is  attentive  to  this  evolutionary 
nature  of  software,  is  more  appropriate  than  a  patent-oriented  standard. 

We  recognize  that  because  software  is  a  hybrid,  lying  somewhere  between  traditional  copyright 
and  patent  subject  matters,  it  is  difficult  to  find  the  appropriate  location  on  the  continuum  as  to 
when  software  is  "developed"  or  not  developed.  The  proposed  DoD  regulatory  standard  would 
seem  to  cal  for  software  to  have  gone  through  extensive  testing  before  it  can  be  deemed 
developed.  We  consider  this  to  be  one  extreme  of  the  continuum.  The  "fixed  in  a  tangible 
medium"  standard  which  we  have  chosen  to  include  in  the  model  clause  may  represent  the  other 
extreme. 

In  choosing  this  standard,  we  were  deferring  to  the  copyright  law  since  that  is  the  nearest  body  of 
intellectual  property  law  applicable  to  software.  We  offer  this  definition  as  a  point  of  discussion, 
and  understand  that  DoD  may  prefer  a  more  operational  definition.  As  a  viable  alternative  to  the 
definition  we  have  presented,  the  DoD  might  consider  a  compromise  between  the  copyright  ap¬ 
proach  to  the  definition  of  "developed"  and  an  operational  definition  which  does  not  require  the 
developer  to  go  to  an  extensive  degree  of  testing  before  software  can  be  deemed  developed.  It 
is  important  that  such  a  definition  recognize  that  software  is  in  a  state  of  continual  development 
and  improvement  which  makes  impractical  any  definition  which  focuses  on  finished  products. 
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This  conflct  points  out  the  predfcament  encountered  by  government  and  industry  alfce  in  dealing 
with  this  strange  hybrid  subject  matter.  To  the  extent  software  is  lice  hardware,  it  would  seem  an 
appropriate  subject  matter  to  hold  to  the  higher,  more  operationally  oriented  standard  of  develop¬ 
ment  under  the  patent  law,  and  to  the  extent  It  is  Hke  technical  data  and  is  subject  to  continual 
modVication,  it  seems  more  appropriate  to  the  more  flexible  standard  for  development  found  in 
the  copyright  law.  This  is  a  dilemma,  but  DoD  has  already  tried  unsuccessfully  to  adopt  a  patent 
standard  for  defining  "developed”  and  found  the  software  industry  to  be  so  hostile  to  it  that 
another  approach  must  be  found. 

2.2.2 .6  Respects  In  which  the  model  standard  rights  In  software  clause  Is  more  advan¬ 
tageous  to  the  DoD  than  the  SDRC. 

In  addition  to  the  benefits  the  DoD  would  realize  as  a  result  of  eliminating  disincentives  which 
cause  some  developers  to  withhold  their  best  technology  from  the  DoD,  there  are  several 
respects  in  which  the  model  standard  rights  in  software  clause  gives  to  the  DoD  broader  rights 
than  those  which  it  would  acquire  under  the  present  treatment  of  software  acquisitions  under  the 
SDRC.  These  include: 

•  the  right  to  reverse  engineer  as  a  minimum  right  in  software  acquisitions; 

•  the  right  to  license  support  contractors  as  a  minimum  right  in  software  acquisitions; 

•  the  right  to  make  derivative  works  as  an  explicit  part  of  the  government  purpose 
rights  package; 

•  a  very  broad  definition  of  government  purpose  rights  which  includes  such  rights  as 
use  or  disclosure  for  competitive  reprocurements,  as  well  as  disclosure  to  and  use  by 
state,  local  and  foreign  governments. 

2.3  If  DoD  Does  Not  Adopt  a  Separate  Rights  in  Software  Clause,  how 
Should  it  Revise  the  Standard  Data  Rights  Clause  to  Improve  its 
Software  Acquisition  Practices? 

Sections  1  and  2  of  this  report  detail  the  reasons  why  a  separate  software  clause  may  be  in  the 
DoD's  best  interests  and  then  sets  forth  a  model  software  rights  clause  for  the  Department’s 
consideration.  In  the  event  the  Department  of  Defense  has  not  been  convinced  of  the  desirability 
of  taking  this  approach,  there  is  still  much  that  can  be  done  to  improve  the  existing  SDRC  as  it 
affects  software.  The  following  22  recommendations  are  distillations  of  many  of  the  points  made 
in  the  First  Report  of  the  SLP.  (Page  and  chapter  numbers  in  parentheses  below  refer  to  the  First 
Report.) 

2.3.1  Definitions 

2.3.1 .1  Don't  overdefine  software  terms. 

Six  software-related  definitions  are  included  in  the  SDRC.  Only  three  seem  to  be  significant  in 
the  body  of  the  standard  data  rights  clause  --  software,  software  documentation,  and  commercial 
software.  Only  these  three  need  to  be  defined.  Also,  the  SDRC  speaks  constantly  of  "computer 
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software"  when  K  is  only  necessary  to  say  "software",  because  "computer”  is  already  included  in 
the  software  definition. 


JL3.1  Jt  if  the  distinction  between  commercial  and  other-than-commerclal  eoftware  la  to  be 
retained,  provide  a  more  precise  definition  of  what  is  meant  by  commercial  computer 
software. 


The  SDRC  provides  for  two  different  sets  of  restricted  rights  applicable  to  privately  developed 
software,  one  tor  "commercial"  software  and  one  for  other  software  (or  commercial  software 
whose  owner  opts  to  have  K  treated  as  other-than-commercial  software).  (Different  restrictive 
legends  are  supposed  to  be  attached  to  software,  based  on  what  kind  of  software  is  to  be 
delivered.)  Unfortunately,  the  existing  definition  of  "commercial  computer  software"  is  so  vague 
as  to  be  a  poor  guide  as  to  what  software  will  qualify  for  commercial  restricted  rights  treatment 
(see  pp.  23-4). 

2.3.1 .3  If  two  sets  of  restrfctsd  rights  for  prtvstsly  dsvslopsd  softwsre  sre  retained,  the 
definitional  section  of  the  clause  should  include  and  define  both  sets  of  restricted  rights. 

As  noted  above,  there  are  two  categories  of  privately  developed  software  which  are  presently 
subject  to  different  sets  of  restricted  rights.  The  definitional  section  of  the  SDRC  sets  forth  only 
one  definition  of  restricted  rights,  which  a  later  section  of  the  SDRC  seems  to  make  applicable 
only  to  other-than-commercial  software.  The  other  set  of  restricted  rights,  those  applicable  to 
commercial  software  (and  Its  documentation),  are  not  set  forth  until  subsection  (b)(3)(H).  In  order 
to  achieve  consistency,  these  "commercial  restricted  rights"  should  also  be  set  forth  in  the  defini¬ 
tional  section  of  the  clause.  (p.  26.) 

2.3.1 .4  Define  what  is  meant  by  "government  purpose,"  perhaps  clarifying  Its  meenlng  by 
providing  some  examples. 

DoD  policy  allows  a  contractor  to  copyright  any  software  developed  under  a  government  contract 
(unless  it  is  a  "special  work").  Subsection  (c)  of  the  SDRC  provides  that  the  contractor  must  grant 
to  the  government  a  copyright  license  "for  government  purposes"  as  to  any  work  in  which  he  has 
taken  a  copyright.  However,  there  is  no  definition  of  "government  purpose,"  either  in  that  subsec¬ 
tion  or  in  the  definitional  section.  This  omission  creates  uncertainty  as  to  the  extent  of  the 
government’s  rights  in  publicly  funded  copyrighted  software  (see  pp.  6, 24-5,  and  Chapter  7). 

2.3.1 .5  Expand  the  definition  of  unlimited  rights  to  Include  the  right  to  prepare  derivative 
works. 

The  present  SDRC  definition  of  unlimited  rights  fails  to  make  explicit  whether  the  government  will 
have  the  right  to  prepare  derivative  works  when  it  has  unlimited  rights  in  software.  Such  a  right  is 
particularly  important  as  to  software  because  maintenance,  enhancement,  reuse,  translation, 
rehosting  and  retargeting  are  al  dependent  on  having  such  a  right  (see  pp.  19, 54, 72).  The  fact 
that  that  the  proposed  Federal  Acquisition  Regulations  (FAR  52.227-1 4(a))  would  give  other 
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governmental  agencies  a  derivative  works  right  in  unlimited  rights  software  would  weaken  DoD’s 
argument  that  the  derivative  works  right  is  implicitly  included  in  Its  unlimited  rights  policy,  in  light 
of  the  importance  of  this  right  to  DoD,  it  would  seem  prudent  (or  DoD  to  take  the  precaution  of 
inducing  the  derivative  works  right  within  its  unlimited  rights. 

2&2  Policy  as  to  Publicly  Funded  Software 

212.1  Clarify  that  unlimited  lights  is  a  kind  of  license,  not  an  ownership  right. 

The  project's  research  revealed  that  DoD  personnel  had  at  least  four  different  interpretations  of 
the  meaning  of  uniimiled  rights  vis  a  vis  ownership  rights..  Intellectual  property  law  would  likely 
treat  imlmfted  rights’  as  a  broad  license,  not  as  an  ownership  Interest.  In  order  to  avoid  future 
misunderstandings  and  possbie  litigation,  this  concept  needs  to  be  clarified 
(see  pp.  24-25,  Chapter  7). 

2123  Clarify  DoD's  Intent  as  to  the  effect  a  contractor's  claim  of  copyright  in  publicly 
funded  software  wH  have  on  the  government’s  lights  In  publicly  funded  software. 

There  is  an  ambiguty  in  the  present  SDRC  concerning  the  extent  of  the  government’s  rights  in 
copyrighted  software  developed  at  public  expense.  One  part  of  the  SDRC  seems  to  give  DoD 
unlimited  rights  in  I  because  it  was  developed  at  public  expense  and  another  part  gives  the 
government  only  government  purpose  rights  ft  the  contractor  decides  to  retain  a  copyright  in  the 
software.  DoD  should  clarify  fts  Intent  on  this  matter. 

212J  If  DoD  dscldea  to  retain  the  apparent  policy  of  showing  a  contractor’s  copyright  to 
Old  back  the  government’s  unlimited  rights  license  to  a  government  purpose  license,  It 
should  require  the  contractor  to  give  DoD  early  notice  of  Ms  Intern  to  claim  copyright. 

A  further  dsadvantage  of  the  present  SDRC  as  regards  contractor  copyrights  in  publicly  funded 
software  is  that  ft  appears  that  the  government  will  typically  not  know  the  extent  of  its  rights  - 
whether  uniimiled  rights  or  government  purpose  rights  -  until  the  software  is  delivered  to  the 
government,  that  is.  untft  it  sees  whether  the  software  was  delivered  with  or  without  a  copyright 
notice  attached.  The  government  may  want  to  require  notice  of  an  intent  to  claim  copyright  at  the 
time  the  contract  is  entered  into  so  that  It  can  plan  accordingly. 

2124  Revise  the  special  works  clause  so  that  DoD  will  be  able  to  take  broader  rights  in 
VmwVi  wnmn  m  nMos  in#m. 

The  DoD's  special  works  clause  (DFARS  52.227-7020)  purports  to  claim  a  direct  copyright  for  the 
government  under  the  "work  for  hire’  doctrine.  This  clashes  with  Section  1 05  of  the  Copyright  Act 
(17  U.S.C.  Sec.  105)  which  prohibits  the  government  from  taking  direct  ownership  rights  in 
copyrighted  works.  Use  of  the  current  special  works  clause  would  seem  to  have  two  effects:  (1) 
to  preclude  the  contractor  from  claiming  a  copyright  in  the  software  and  (2)  to  put  the  software 
into  the  pubftc  domain,  since  neither  the  government  nor  the  contractor  can  own  it. 
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Since  copyright  I aw  does  permit  the  government  to  own  copyrights  by  assignment,  a  copyright 
strategy  simHar  to  that  adopted  by  NASA  and  proposed  lor  the  FAR  should  be  considered  by 
DoD.  (p.  21,  Chapter  5.) 

DoD  should  either  give  up  Its  claim  of  unlimited  rights  In  non-dellverable  software 
or  make  a  deterred  ordering  clause  standard. 

The  SDRC  eeems  to  give  the  government  unlimited  rights  hi  several  categories  of  software, 
afthough  their  deKvery  may  not  be  required  by  the  contract  (SDRC  (b)(i).)  Without  the  inclusion  of 
a  deterred  ordering  clause,  It  appears  that  the  government  would  not  have  the  right  to  require 
delivery  of  any  of  this  non-deliverable  software.  The  existence  of  this  unenforceable  inchoate 
right  only  serves  to  frustrate  both  the  government  and  industry. 

We  recommend  that  DoD  examine  whether  it  needs  to  claim  unlimited  rights  in  these  norv 
deNverables.  If  ft  is  decided  that  such  a  right  is  needed,  a  deferred  ordering  clause  should  be 
made  a  standard  part  of  the  contract  (see  pp.  19-20). 

2 .3^.6  in  "mixed  funding"  situations,  (La.,  where  both  public  and  private  funds  are  used 
to  develop  the  software  DoD  should  provide  an  option  for  the  government  to  take  less  than 

i  mllmlln  ri  rlnt^a  V 

unwnMO  ngrvs.) 

This  would  provide  needed  incentives  to  software  firms  to  invest  some  of  their  own  capital  in 
software  development  which  could  result  in  a  higher  quality  product  and  in  lower  initial  acquisition 
costs.  It  would  also  conform  with  the  apparent  congressional  intent  reflected  in  Section  2320  of 
the  Department  of  Defense  Authorization  Act  of  1985,  (Public  Law  98-525, 10  U.S.C.  Sec.  2301 , 
2320.) 

One  poesftrftfty  would  be  to  give  the  government  unlimited  rights  in  software  developed  with 
predominantly  pubRc  funds  (whether  or  not  the  software  is  copyrighted)  and  to  take  only 
"government  purpose  rights"  when  funding  is  predominantly  but  not  exclusively  private  (see  pp. 
38-39). 

222.7  Surrender  the  potential  unlimited  rights  claim  to  software  documentation  that 
might  be  In  a  manual  or  that  might  be  construed  as  Instructional  material  for  Installation, 
operation,  maintenance  or  training  purposes. 

Under  the  SDRC,  the  DoD  acquires  unlimited  rights  in  manuals  or  instructional  materials 
prepared  or  required  to  be  delivered  under  a  government  contract  for  installation,  operation, 
maintenance  or  training  purposes,  even  though  such  manuals  may  have  been  developed  at 
private  expense  and  are  not  in  the  public  domain. 

Afthough  privately  developed  other-than-commercial- software  may  receive  restricted  rights  treat¬ 
ment,  manuals  or  instructional  materials  for  such  software,  even  though  they  contain  proprietary 
information,  would  seem  to  be  governed  by  the  unlimited  rights  provision.  This  creates  a  sig¬ 
nificant  dsincentive  to  do  business  with  DoD  and  could  lead  to  firms  providing  the  government 
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with  no  more  than  the  barest  minimum  of  documentation  needed  to  meet  contract  requirements 
(see  pp.  23*24). 

2J3J2&  Examine  the  need  lor  “unlimited  lights"  as  opposed  to  "rights  for  government 
purposes". 


In  accordance  with  the  regulatory  policy  that  DoD  shall  acquire  only  such  rights  to  use,  duplicate 
and  disclose  software  developed  at  private  expense  as  are  necessary  to  meet  government 
needs,  consideration  should  be  given  to  restructuring  the  unlimited  rights  policy  to  afford  the 
government  unlimited  rights  only  where  they  are  truly  needed  (see  pp.  38-43). 


2J3J3  Policy  as  to  Privately  Funded  Software 

2&3.1  Add  to  the  minimum  restricted  tights  the  government  obtains  In  privately 
developed  software  the  right  to  make  a  copy  for  reverse  engineering  purposes  If  neces¬ 
sary  to  make  mocHfkntlons. 

The  restricted  rights  provisions  of  the  SDRC  seems  to  limit  the  government's  right  to  copy 
software  to  archival  or  back-up  purposes.  Although  the  minimum  rights  do  include  the  right  to 
modify  the  software,  if  insufficient  documentation  has  been  obtained  or  it  is  not  possible  to  have 
the  original  contractor  modify  the  software,  the  government  may  attempt  to  reverse  engineer  it.  It 
is  not  dear  under  the  regulations  or  the  copyright  law  whether  the  modification  right  includes  the 
right  to  make  a  copy  for  reverse  engineering  purposes.  In  light  of  the  potential  risks,  it  would  be 
prudent  for  DoD  to  clearly  state  that  it  has  this  right,  (p.  55.) 

2.3JJf  Develop  a  standard  policy  for  acquiring  privately  developed  software  for  local  area 
networks. 

Since  local  areas  networks  which  share  software  are  becoming  more  commonplace  within  DoD, 
the  regulations  should  provide  guidance  about  acquiring  software  intended  for  use  in  such  net¬ 
works.  (p.  27-28.) 

2.3 J3J3  Clearly  establish  the  status  of  restricted  rights  software  which  the  government  has 
modified. 

When  the  government  modifies  privately  developed  software  in  which  it  has  restricted  rights,  the 
effect  of  that  modification  appears  to  vary,  depending  on  whether  the  software  is  subject  to  com¬ 
mercial  or  other-than-commercial  restricted  rights.  The  SDRC  provides  that  as  to  commercial 
software,  "unmodified  portions  shall  remain  subject  to  these  restrictions."  However,  modifications 
fo  other  than  commercial  software  are  governed  by  another  subsection  of  the  clause,  which 
provides  that  "those  portions  of  the  derivative  software  incorporating  restricted  rights  software  are 
subject  to  the  same  restricted  rights."  This  apparently  Inconsistent  treatment  of  modifications  to 
restricted  rights  software  is  extremely  confusing  and  needs  to  be  clarified,  (p.54-5.) 
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The  ambiguity  of  the  DoD  regulations  about  ownership  rights  and  restrictions  as  to  software 
modifications  may  mean  that  K  the  original  software  is  protected  by  copyright  law,  it  is  copyright 
law  that  will  fin  in  the  gaps.  Since  modifications  are  derivative  works,  a  host  of  copyright  issues 
could  arise  which  could  substantially  inhibit  the  government’s  use  of  the  software  to  its  maximum 
potential.  (Chapters) 

2.3 .3.4  Consider  eliminating  the  two  different  sets  of  restricted  rights  for  commercial  and 
other-than-commercial  software  developed  at  private  expense. 

As  noted  above,  the  SDRC  provides  for  two  different  sets  of  restricted  rights  for  commercial  and 
other-than-commercial  software.  There  appears  to  be  no  clear  rationale  for  this  differential  treat¬ 
ment  and  for  the  corresponding  differential  treatment  of  documentation.  Moreover,  neither  the 
regulation  nor  policy  provision  provide  any  clear  guidance  as  to  when  a  piece  of  software  qualifies 
for  commercial  or  other-than-commercial  treatment. 

The  resulting  confusion  and  ambiguity  can  be  avoided  by  establishing  a  "floor'  of  minimum  rights 
which  the  government  must  have  and  then  allowing  arrangements  between  the  "floor"  of  min¬ 
imum  rights  and  the  "ceffng"  of  unlimited  rights  to  be  negotiated  as  the  government’s  needs 
require  (see  pp.  26-27). 

2.3J3A  If  DoD  chop— a  to  retain  the  distinction  between  commercial  and  other-than- 
commercial  software,  eliminate  the  potential  unlimited  rights  claim  In  privately  developed 
other-than-commercial  software  as  to  which  no  separate  license  agreement  has  been 
negotiated. 


When  other-than-commercial  software  is  being  procured,  the  SDRC  stipulates  that  a  separate 
license  agreement  containing  the  applicable  restrictions  is  to  be  negotiated  and  made  a  part  of 
the  government  contract,  (so  long  as  the  government  obtains,  at  a  minimum,  the  four  minimum 
restricted  rights  set  forth  in  the  clause).  When  a  firm  provides  privately  developed  software  to 
DoD  but  has  not  negotiated  a  separate  licensing  agreement,  an  issue  arises  as  to  whether  the 
government  would  get  unlimited  rights  in  the  software  or  only  the  four  minimum  restricted  rights. 
The  existence  of  such  a  potential  "booby  trap’  in  the  regulations  could  be  enough  to  dissuade  the 
smaller,  "high  tech"  companies  from  doing  business  with  DoD  with  the  result  that  the  latest  in¬ 
novative  software  could  be  unavailable  (see  pp.  21-23).  The  SDRC  should  be  revised  to  make 
clear  that  the  government  will  have  only  the  four  standard  minimum  rights  in  privately  developed 
other-than-commercial  software  when  no  separate  licensing  agreement  is  negotiated. 

2.3J.6  Treat  privately  developed  software  documentation  at  subject  to  the  same  restric¬ 
tions  as  the  machine  readable  code. 

The  SDRC  treats  commercial  computer  software  and  its  documentation  in  a  manner  consistent 
with  industry  practice  by  providing  that  both  machine  readable  code  and  documentation  will  be 
governed  by  the  same  set  of  restricted  rights. 

In  contrast,  documentation  for  other-than-commercial  software  is  not  subject  to  the  same  set  of 
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restricted  rights  as  the  machine  readable  code  but  is  instead  acquired  by  the  government  with 
Rmfted  rights.  This  gives  the  government  the  right  to  use,  disclose  and  duplicate  the  documen¬ 
tation  throughout  the  government.  Subjecting  other  than  commercial  documentation  to  the 
broader  Imted  rights  policy  not  only  causes  confusion  but  deters  many  software  firms  from  sell¬ 
ing  rights  in  their  most  valuable  technology  to  DoD.  (p.  26-27.) 

23.3.7  Allow  contractors  to  retain  the  privately  developed  status  for  software  when  only 
minor  modifications  are  made  to  tailor  it  for  government  use. 

Under  the  DoD  policy,  if  a  company  has  developed  a  piece  of  software  wholly  at  private  expense, 
and  then  under  a  government  procurement  contract,  makes  some  minor  modifications  to  tailor  it 
for  intended  government  use,  the  company  would  forfeit  restricted  rights  status  for  the  delivered 
software  >  DoD  funds  subsidized  the  modification.  This  policy  deviates  from  standard  commer¬ 
cial  practice,  and  is  viewed  by  many  software  firms  as  inequitable. 

Consideration  should  be  given  to  adopting  the  proposed  FAR's  more  flexible  approach  which 
aHows  contractors  to  retain  the  privately  developed  status  for  their  software  when  only  minor 
modifications  are  made  for  the  government  (see  pp.  25-26). 

2.33.8  Consideration  should  be  given  to  restructuring  the  software  procurement  process 
so  as  to  allow  the  government  the  flexibility  to  take  less  than  the  current  minimum 
restricted  rights  In  software  and  less  than  limited  rights  In  documentation  In  certain 
situations. 

In  some  situations  it  may  be  in  the  government’s  best  interests  to  have  the  flexibility  to  acquire 
fewer  rights  in  privately  developed  software  than  the  current  SDRC  permits  in  exchange  for  cer¬ 
tain  concessions  from  the  contractor.  This  built-in  flexibility  could  allow  the  DoD  to  satisfy  a  more 
pressing  need  such  as: 

a)  the  need  to  get  a  warranty  on  the  software  which  may  not  be  possible  unless  the  government 
agrees  to  permit  the  developer  to  perform  all  the  maintenance  work  (Chapter  11); 

b)  the  need  to  create  an  escrow  arrangement  to  obtain  access  to  privately  developed  source 
code  that  the  software  firm  would  otherwise  not  provide  at  reasonable  cost  to  the  government 
(see  pp.  52-53);  and 

c)  the  need  to  get  access  to  software  tools  and/or  CAD/CAM  programs 
(see  pp.  50-51 ,  Chapter  1 0). 

2333  Rename  the  proposed  "license  rights"  provision  of  the  proposed  SDRC,  if  a  "fixed 
expiration"  option  la  to  be  preserved. 

The  "icense  rights"  concept  as  originally  conceived  by  the  OSD  Study  Group  was  to  enable  the 
government  to  require  its  contractors  to  license  competitors  to  use  their  proprietary  data  in  com- 
petttve  reprocurement  (or  maintenance)  situations.  However,  the  license  rights’  option 
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proposed  by  the  DoO  FAR  Supplement  appears  to  focus  on  obtaining  expirations  for  restrictive 
legends.  "License  rights'  is  a  misnomer  for  this  set  of  rights,  particularly  in  view  of  the  fact  that 
the  SBIR  provisions  reflect  a  very  different  license  rights"  policy.  Give  the  new  policy  a  better 
name,  perhaps  "fixed  expiration  rights,"  so  that  people  won’t  get  confused.  It  is  questionable 
whether  this  new  option  will  be  acceptable  to  industry  which  can  always  elect  limited  or  restricted 
rights  protection  for  its  valuable  technologies  (see  pp.  32-35). 
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3.  Conclusion 

It  is  important  to  observe  that  the  problems  which  DoD  is  experiencing  with  its  software  acquisi¬ 
tion  policy  are  not  unique  to  the  government.  The  problems  are  being  experienced  industry-wide, 
and  are  due  in  large  part  to  the  unique  nature  of  software  and  to  the  lag  between  the  ability  to 
conceptualize  software  as  a  product  and  the  development  of  the  end  product.  The  DoD,  as  the 
major  single  consumer  of  software,  is  in  a  unique  and  enviable  position  to  address  the  difficulties 
being  encountered  within  the  software  industry,  and  to  place  itself  on  the  leading  edge  of  the 
effort  to  bring  acquisition  and  licensing  practices  in  line  with  the  technical  and  economic  realities 
of  software  development.  By  taking  this  leadership  role,  the  DoD  could  do  much  to  help  maintain 
the  U.S.  lead  in  software  technology  in  the  world. 
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